The basic copy protection mechanism is described in copending application Ser. No. 927,629; this mechanism separates the software which is to be protected from the right to execute that software. To provide security and implement the mechanism, each computer on which a protected application is to run (hereinafter referred to as a host) is associated with a logically and physically secure coprocessor. When installed in the coprocessor, the right-to-execute a particular protected application exists in the form of a software decryption key called an application key (AK). So long as the software decryption key AK is retained in the permanent memory of the coprocessor, the corresponding protected software can be executed on the composite system including the host and coprocessor. The software copy protection mechanism has the advantage that it negligibly interferes with present and contemplated software distribution techniques, it allows the user to make unlimited numbers of "backup" copies and it does not require any two-way communication between the user and the software vendor. This is supported by distribution of an authorization to the coprocessor to accept a right to execute provided in the form of a hardware cartridge (or token). Furthermore, the user need only employ the token the first time the protected application is run in order to transfer the right to execute, which is represented by the unused token, to the coprocessor. Thereafter, the token may be discarded and it is thereafter totally unnecessary to maintenance or use of the right to execute.
The invention described in copending application Ser. No. 927,629 does not address manipulation of the right to execute (other than describing how a user may first acquire it), nor does it describe the possibility of conditioning the right to execute. The present invention is particularly directed at conditioning or manipulating or transferring the right to execute which exists in a coprocessor.
In particular, the present invention provides the capability of safely transferring the right to execute. The right to execute may be transferred to another coprocessor or may be merely transferred outside the coprocessor for external storage. In either event it is essential that the process of transferring the right to execute not generate or allow spurious or duplicate rights to execute which would of course defeat the purpose of the copy protection mechanism. As described herein, the transfer of a right to execute can be indirect, through the use of a transfer set (which in many respects is identical to the distribution set through which the right to execute was acquired) or direct via a coprocessor to coprocessor communication link. Safety is maintained even though the communication is unsecured in the sense that the transfer transaction may be observed.
The present invention also provides techniques for conditioning the right to execute. For example, the right to execute might be conditioned by a time period (a right to execute which exists up until a cut-off date and/or time) or it could be conditioned based on the number of times it is invoked (for example the vendor could sell a user the right to execute the protected application ten times). As will be described, the right to execute can be conditioned on any other parameter so long as it can be measured by the coprocessor to the satisfaction of the source of that right to execute (the software vendor). The availability of conditioned rights to execute provides the software vendor with additional flexibility and it further opens up the possibility, for the first time in the software field, of a truly safe "return" policy. For obvious reasons, a software vendor, using today's software distribution techniques, will be in jeopardy of giving his products away free if he accepts the "return" of software for full purchase credit. The vendor has no way of verifying with present distribution techniques whether or not the user has already duplicated the software so that after the return the user could still maintain a fully usable copy of the application. Using the principles described herein, however, the software vendor can implement a " return" policy and be assured that if a user returns the software, the user no longer retains an executable copy.
Because the software copy protection mechanism operates in the real world, with real world devices, and because the distinct right to execute exists in the form of a cryptographic key stored in the permanent memory of a coprocessor, it is necessary to address the possibility that the coprocessor storing the right to execute may fail. Such failure should not result in the complete loss of the user's rights to execute, and the present invention provides apparatus and methods for securing the user against the loss of the right to execute in the event his coprocessor does fail. Much as in the case with moving or transferring the right to execute, any hardware "backup" technique (available in case a coprocessor fails) should not have the property of being useful to generate spurious rights to execute. The hardware backup method provides minimal opportunity (and significant disincentive) for improperly multiplying rights to execute.